<h2>Play with this demo</h2>
<p>
In this Activity, you can : 
<ul>
  <li> start an AsyncTask and see the progress ;
  <li> cancel a started AsyncTask ;
  <li> start an AsyncTask, rotate the device and observe that UI is not updated anymore ;
  <li> simulate a memory leak : rotate the device and start an AsyncTask, repeat 20 times. You can see memory is getting 
  lower and lower after each rotation.
</ul>
</p>

<p>
Read below to learn more.
</p>

<h2>Basic AsyncTask usage. </h2>

<p>
In this app, the first serie of activities is dedicated to AsyncTasks. It aims to highlight all the problems related
to using the AsyncTask framework of Android for implementing background processing. This serie is largely inspired by 
a question on Stack Over Flow : <a href="http://stackoverflow.com/q/3357477/693752">Is AsyncTask really conceptually flawed or am I just missing something ?</a>
and the answers it received from the community.
</p>

<p>
This Activity uses a simple AsyncTask. <br>
</p>

<h3>Memory leak issue</h3>

<p>
In this Activity, the AsyncTask is an inner class of the Activity. This looks like a natural choice : as the AsyncTask will need to manipulate the views 
of the Activity when the task is complete or in progress. Using an inner class of the Activity seems convenient : inner classes can 
access directly any field of the outer class.
</p>

<p>
<em>Nevertheless, it means the inner class will hold an invisible reference on its outer class instance : the Activity.</em> 
</p>

<p>
On the long run, this produces a memory leak : if the AsyncTask lasts for long, it keeps the activity "alive" 
whereas Android would like to get rid of it as it can no longer be displayed. The activity can't be garbage collected and that's a central
mechanism for Android to preserve resources on the device. 
</p>

<p>
Depending on the size in memory of your Activity, you will quickly get an <tt>OutOfMemoryException</tt>, as none of those activities 
will get garbage collected by the Android system. In this tutorial, we simulated this failure : every instance of this class of Activity as 
a big buffer that fills up the ram. Rotate your device, and click on start. Repeat the process again and again. After 20-25 times you should
 get a memory exception due to the memory leak problem we mention here.
<p>

</p>
If you don't understand why activities must die, please refer to the activity life cycle of the 
<a href="http://developer.android.com/reference/android/app/Activity.html#ActivityLifecycle"/> Activity documentation</a>.
</p>

<h3>The AsyncTask and Activity life cycle</h3>

<p>
AsyncTasks don't follow Activity instances' life cycle. If you rotate the device, the Activity will be destroyed and a new instance will be created.
But the AsyncTask will not die. It will go on living until it completes. This a nice mechanism for long-running background operations.
Nevertheless, it's not managed correctly by AsyncTasks and most benefit of it are lost.
</p>

<p>
Click on the start button, then rotate your device. 
As you can see, once the Activity is recreated, the former AsyncTask doesn't update the UI anymore. Indeed it updates the former instance of the activity that
is not displayed anymore. This can lead to an Exception of the type <tt>java.lang.IllegalArgumentException: View not attached to window manager</tt> if you
use, for instance, <tt>findViewById</tt> to retrieve a view inside the Activity (here we don't do that, we use data members to hold references on views).
</p>

<p>
But even if you don't get an exception, you just lost the link between UI and background task. We will demonstrate a workaround in the next demo Activity.
</p>


<h3>Canceling an AsyncTask</h3>

<p>
To cancel an AsyncTask is easy, but only if the AsyncTask supports it ! Invoking the <tt>cancel</tt> method will 
have no effect by itself. But, if the AsyncTask, during its <tt>doInBackground</tt> method regularly checks the <tt>isCancelled</tt> flag, 
then it can decide to stop itself on demand. We implemented such a solution in all our AsyncTask if you are looking for sample code.
</p>

<hr>
Other examples propose some workarounds to these issues. Go back to the menu and click on the next demo Activity. You can play with the app and experiment
all limitations mentionned above. Please don't tell us this Activity crashes, it will crash on design !
